Klarna Payments

Klarna allows online customers to purchase goods and pay later (up to 30 days depending on the market), or in instalments. This credit arrangement is between Klarna and the customer. Klarna pays the merchant, and the customer pays Klarna back, eliminating any risk for the merchant.

AltaPay offers integration into Klarna Payments as standard, supporting Pay Later and Financing. (Pay Now is not an invoice solution, and is not supported by AltaPay.) The previous product, Klarna KPM is deprecated from September 2020.

We currently support Klarna for Pay Later, which is invoicing; and Financing, which allows the customer to pay for the goods in instalments. For both options, you receive the money from Klarna after an agreed period of time. As the merchant, you are not affected by the option in terms of settlement.

We support One Klarna, which allows the consumers to pay with multiple payment methods. Request your MID to be configured by Klarna, and the solution will work out of the box once the changes are applied.

AltaPay supports B2B and B2C purchases in all countries that are supported by Klarna. See B2B Orders for more details.

If you previously used Klarna KPM, your agreement will apply for Klarna Payments. Simply upgrade your integration and enjoy the benefits of the new Klarna Payments offering. These benefits include increased speed, a single integration for all Klarna payment methods, global compliance, exposure to new markets, including the UK, and opportunities to increase conversions. (With Klarna Payments, you can send more customer information to Klarna, which will increase approval rates, and you can offer prefilled details at the checkout.) Klarna, in turn, will provide the customer with more detailed information about the rates and fees potentially incurred. See Differences between Klarna KPM and Klarna Payments and https://www.klarna.com/international/business/upgrade-solution/ for more details.

How it works

There are two stages involved in processing payment for goods using Klarna Payments - reservation of payment; and capture of payment. During payment reservation, Klarna evaluates the customer based on the information sent by the merchant, and then presents the customer with the choice of payment methods eg Pay Later or Invoicing (previously called "Slice-it"). When the customer selects one and provides relevant additional information, the payment is reserved.

Reserving a Payment

This is the first stage of processing the payment, when the order is placed by the customer and Klarna authorizes the payment. The following diagram illustrates the steps involved in reservation of payment that are relevant to you as a merchant.

1. The customer goes to your checkout page, and selects Klarna as the payment method.
The Klarna payments are displayed generically as, for example, "Klarna" or "Pay with Klarna". The specific Klarna payment options will be displayed at a later stage. Any Klarna branded information should be displayed according to brand guidelines. Klarna's logotypes (invoice and/or part payment) must be visible on the start page, and placed next to the payment options in the checkout. You can download the Klarna logo from https://developers.klarna.com/resources/branding-visuals/
2. You (the merchant) send a createPaymentRequest to AltaPay, including the customer and order details, and specifying Klarna as the selected payment method.
You should send as much information as possible to Klarna, regarding both the customer and the order, to help increase the conversion rate, and reduce the amount of information that the customer needs to key into the Klarna interface. It also improves Klarnas risk evaluation.
3. AltaPay returns the payment id and redirect URL to you, and you then redirect the customer to the AltaPay secure payment page, based on the response.
See Payment Page (callback_form) for more details on how to do this.
4. The customer's browser connects to AltaPay's secure payment page.
5. AltaPay initiates a call with Klarna, passing all available data including billing address, shipping address, shipping options, order details, order amount, locale and merchant URLs.
This is GDPR compliant because the customer has already selected the Klarna payment option.
6. Klarna completes a pre-assessment based on the order details, to establish the payment method categories they are prepared to offer.
7. They return to payment method categories, along with logo and parameters to AltaPay.
8. AltaPay displays the available Klarna payment options to the customer, using the load call.
9. The customer selects the required payment option and AltaPay sends an Authorize call to Klarna, with the payment method category.
10. Klarna conducts a customer risk assessment to establish whether they are prepared to offer the customer that amount of credit.
11. There is a further exchange between AltaPay and Klarna, resulting in an order from Klarna to AltaPay to establish the payment method details selected by the customer. The response includes all of the order details, including extended payment details.
12. You (the merchant) receive a confirmation from AltaPay when the transaction has been processed, including the billing address the amount/currency and selected payment details.
13. You should validate the returned amount and currency, and then show or redirect the customer to the appropriate message page, confirming success or informing them of any problem with the payment.
The specific Klarna decline message must be shown to the customer, as indicated by the CardHolderMessageMustBeShown XML return element.

This is the standard payment flow for the initial reservation. There may be slight changes to this flow, depending on certain conditions.

Parameters for Reserving a Payment

You use the createPaymentRequest method in the Merchant API to pass information to AltaPay.

Post Reservation Processing

There are a number of possible actions that take place after the reservation phase:

• Capture, which is the second phase of processing the payment. You can find out more about the different capture scenarios below.
• Cancellation of the payment, in which the entire order is cancelled. You cannot cancel the transaction if any capture, including partial capture, has taken place.
• Refunding some or all of a payment. You can only refund captured amounts. You cannot over refund.

Capturing a Payment

This is the second phase of processing the payment, when the payment is "claimed" by the merchant from Klarna. Typically this takes place when the goods are shipped to the customer.

There are several capture scenarios, including:

• Full capture, in which the entire order is fulfilled and all funds are captured
• Partial capture, followed by another partial capture to complete the order
• Partial capture, without a follow up to complete the order

The flow is as follows:

Parameters for Capturing Payments

To capture a payment, create a capture request, using the captureReservation method, with the following parameters:

Parameter	Description	Type	Mandatory
amount	This is the gross amount to be captured (including taxes). If you do not want to capture the full amount, a smaller amount can be captured. The amount must be greater than 0.00, and equal to, or lower than the reserved amount.	float	Yes
orderLine	Value Description Type Mandatory description Description of an item. String (255) Yes itemId The item identification. Each itemId must be unique within an order. String (100) Yes quantity The quantity of the item. The value must be greater than zero. Decimal Yes unitPrice The unit price, excluding sales tax. The value must be greater than zero, unless the optional goodsType parameter is set to handling, in which case the field can be used to provide a discount. Decimal Yes taxPercent This is the tax percentage of the unit price. Send both the taxPercent and taxAmount parameters in the method call. If you provide only one, the other is inferred, and rounding errors may occur. The taxAmount is used for the calculation, and taxPercent is printed on the invoice. Decimal No taxAmount This is the total tax on an order line, before any discounts are applied. It is recommended to use taxAmount if possible. If you provide both taxPercent and taxAmount, the amount takes precedence. Send both the taxPercent and taxAmount parameters in the method call. If you provide only one of the taxPercent and taxAmount parameters, the other parameter is inferred, and rounding errors may occur. The taxAmount is used for the calculation, and taxPercent is printed on the invoice. Decimal Yes unitCode The relevant measurement unit for the order line. For example, kg. String (50)   discount The order line's discount in percent. Decimal   goodsType The goods type of the order line - shipment| handling| item| digital| discount| gift_card| info| physical| sales_tax   Yes imageUrl The full URL of the icon for the item String (255)   productUrl The full URL for the description of the item String (255)		Recommended
reconciliation_identifier	This is the sales reconciliation identifier, used in the reconciliation CSV files you can download from the Merchant Interface, or by using the getCustomReport method. For more information, see getCustomReport.	String{0,100}
sales_tax	The sales tax amount. Indicates how much of the gross amount that was sales tax, e.g. VAT (UK) or Moms (DK).	float
trackingInfo[]	Tracking information, in an array. Could include: trackingId Id of the tracking. Maximum 100 characters. refTrackingId Id of the referred tracking. Maximum 100 characters. Used to identify the related tracking. For Klarna Payments this can be used to link the return tracking to the shipping tracking. companyName Name of the shipping company. Maximum 100 characters. You are advised to be as specific as possible, including the region/branch, etc where appropriate method Allowed values matches (PickUpStore|Home|BoxReg|BoxUnreg|PickUpPoint|Own) trackingNumber Tracking number for the shipment. Maximum 100 characters trackingUri URL where the customer can track their shipment. Maximum 1024 characters type Type of the tracking information. Possible values: SHIPPING, RETURN trackingInfo[0][trackingId] = 1 trackingInfo[0][companyName] = Mærsk trackingInfo[0][method] = PickUpStore trackingInfo[0][trackingNumber] = 123abc trackingInfo[0][trackingUri] = www.tracking.com/id trackingInfo[0][type] = SHIPPING trackingInfo[1][trackingId] = 1 trackingInfo[1][refTrackingId] = 2 trackingInfo[1][companyName] = ReturnCo trackingInfo[1][trackingNumber] = 456abc trackingInfo[1][trackingUri] = www.tracking.com/id2 trackingInfo[1][type] = RETURN See https://docs.klarna.com/api/ordermanagement/#operation/captureOrder Please make sure you passed same number of tracking info of SHIPPING type with the RETURN type so that it can be mapped correctly with the KlarnaPayments shipping_info	Array	Optional but recommended
transaction_id	The id of a specific payment.	[0-9a-f]{1,32}	Yes

Processing a Partial Capture

There may be a delay in shipment of some of the goods, which results in several partial captures.

You do the final capture for the remaining items when they become available. This must be completed within twenty-eight days of the original order reservation, unless you have agreed an extended payment period with Klarna.

To partially capture the payment, you call the captureReservation method.

You should include the captured order lines in the order. Klarna can then match the amount and show the customer on the Klarna app which products have been captured.

All components of the order line in the partial capture must exactly match the order line from the original payment.

Updating Orders

For Klarna Payments, through updateOrder method, the AltaPay Payment Processing Service allows you to:

1. Update order lines and amount

   Using the updateOrder endpoint, send the order lines and the amount you would like to change. For more information about updating order lines and amount please see the Notes section on updateOrder page.

2. Update tracking information

   Using the updateOrder endpoint, send the trackingInfo parameter to update the information. You will be required to associate shipping and returns together. See the updateOrder page for more information.

3. Update customer information

   Using the updateOrder endpoint, send the customer_info parameter to update the customer information.

4. Trigger resend of customer communication

   When the payment is in captured state and the terminal is configured, you can notify the customer on updating the order. To enable the notify customer functionality with Klarna Payments, please contact our support team.

Parameters for Updating orders

To update an order, create a update order request, using the updateOrder method, with the following parameters:

Processing a Refund

Refunds take place after the capture of funds. There are several refund scenarios.

• Full refund, which returns the funds for the entire transaction
• Partial refund, which returns the funds for some of the order lines
• Goodwill refund, which you can use to refund an arbitrary amount, independent of the existing order lines. You cannot refund more than the captured amount.

The flow is as follows:

Note the following when managing refunds:

• You can only refund up to the captured amount.
• You can refund multiple captures in a single refund, as long as they are all part of the same transaction/order.
• You cannot refund from multiple orders/transactions in a single refund.
• Goodwill refunds can be processed, as described below.

Goodwill Refunds

Merchants can offer goodwill refunds if required, noting the following:

• The total amount of all refunds cannot exceed the captured amount on the order.
• You should submit goodwill refunds on a separate refund request to any other refund, leaving the orderLine details blank.

Parameters for Processing Refunds

If order lines are not provided in a refund, Klarna will check whether an order or order line amount matches the refund amount. If they match, Klarna will display the refunded order line(s) to the customer in the Klarna app. If the figures do not match, Klarna will perform the refund but will not display any items to the customer.

Supported Countries for B2C

Klarna Payments (for B2C) is supported by AltaPay in the following countries, locales and :

 

Country	Purchase country	Currency **	Locales*	Country specific Requirements
Austria	AT	EUR	de-AT, en-AT
Denmark	DK	DKK	da-DK, en-DK
Germany	DE	EUR	de-DE, en-DE	To adhere to German data protection laws, the customer must actively consent (via a checkbox) to a specific text, both for Klarna Invoice and Klarna Account. The text needs to be generated based on text snippets from Klarna, found here: http://developers.klarna.com/en/dynamic-store-assets/consumer-terms-conditions (Select Germany as the country, EID is not needed).
Netherlands	NL	EUR	nl-NL, en-NL	It is required by law to show a banner warning your customer that it costs money to borrow money. This is managed by Klarna.
Norway	NO	NOK	nb-NO, en-NO	Norway has some very strict requirements for the Klarna Account option. For detailed information, see: https://developers.klarna.com/en/no/kpm/consumer-terms-and-conditions (Klarna Campaign is not relevant because it is a special product offered). You must only send goods to the publicly registered address.
Sweden	SE	SEK	sv-SE, en-SE	For Swedish customers, Klarna does an address verification. If the address your customer enters differs from the registered address, your customer needs to approve the updated address. The updated address is returned via the <RegisteredAddress> XML response element. You can set up your terminal so that transactions are declined if the addresses do not match.
Switzerland	CH	CHF	de-CH, fr-CH, it-CH, en-CH
United Kingdom	GB	GBP	en-GB

B2B Orders

Klarna Payment for B2B invoice payment orders is supported in Germany, Norway, Sweden and Finland.

Country	Purchase country	Supported Locales*	Supported Currency**	Country specific Requirements
Finland	FI	fi-FI, sv-FI, en-FI	EUR
Germany	DE	de-DE, en-DE	EUR	To adhere to German data protection laws, the customer must actively consent (via a checkbox) to a specific text. The text needs to be generated based on text snippets from Klarna, found here: http://developers.klarna.com/en/dynamic-store-assets/consumer-terms-conditions (Select Germany as the country, EID is not needed).
Norway	NO	nb-NO, en-NO	NOK	You must only send goods to the publicly registered address.
Sweden	SE	sv-SE, en-SE	SEK	Klarna does an address verification. If the address your customer enters differs from the registered address, your customer needs to approve the updated address. The updated address is returned via the <RegisteredAddress> XML response element. You can set up your terminal so that transactions are declined if the addresses do not match.

Parameters for B2B

As well as the standard parameters for createPaymentRequest, if you are integrating Klarna Payments for B2B transactions, be aware of the following parameters:

Parameter	Description	Type	Mandatory
customer_info[type]	Indicator of whether the customer is an individual or a business	private business	Ensure that this is business
customer_info[company_name]	Name of the customer	string	Yes
customer_info[company_type]	The nature of the company	ltd - limited company plc - public limited company public_institution - public institution other - all other company types	Yes
customer_info[vat_id]	The company's VAT registration number	string	No
	The company's registration number	string	No
customer_info[billing_att]	The name of the person or department managing the billing for the company	string	No
customer_info[shipping_att]	The name of the person or department receiving the purchase on behalf of the company	string	No
customer_info[billing_address]	The street address of the customer's billing address.	string	Yes, for DK, FI and DE
customer_info[reference]	A reference, for example, cost center, that can be used to track the order	string	No

Features that are not currently supported

The following features are not supported:

Feature	Description
Over refund	It is not possible to refund more than the captured amount.
Credit	It is not possible to create credit transactions.
Subscriptions	It is not possible to set up subscriptions.

Differences between Klarna KPM and Klarna Payments

If you have been using Klarna KPM, you should note the following differences with the introduction of Klarna Payments:

• You should see higher conversion rates, if you send more data regarding the customer to Klarna, because Klarna is then more likely to offer a payment method to the customer.
• If you use(d) Klarna KPM, you will have logic in your sales flow that invoices Klarna, and sends them an invoice when a customer pays using Klarna KPM. With Klarna Payments, this logic is not required. There is no special case needed for Klarna – all sales payments (Klarna, Creditcards etc) are handled normally, invoicing the customer and, optionally, sending the invoice to them.
• You can now send URLs/links with the orderlines to product description and product images.
• Klarna will display any instalments, rates and fees associated with the actual order to the customer.
• Business2Business is now supported through Klarna Payments
• New orders will have an expiration date of 28 days from the day the order was created by default, although this can be negotiated with Klarna. If you don’t capture the order before it expires, it will be cancelled automatically.

Migrating from Klarna KPM

Klarna KPM is being deprecated in 2020, in favour of Klarna Payments. Klarna Payments will offer you and your customers more functionality, and allow you to benefit from future developments roadmapped by Klarna.

When migrating from Klarna KPM to Klarna Payments, bear the following in mind:

• Both payment methods can be run at the same time, using different terminals, and you will get a new e-store ID. You should set up test versions of Klarna Payments on a small subset of your terminals to ensure smooth transition. Simply integrate Klarna Payments as a new payment method, and when you have completed testing and are confident of the new functionality, migrate your terminals over to Klarna Payments.
• You should not run both payment methods on the same terminal, as it will cause operational issues.
• An order must run to completion on the chosen payment method, which means that even when you are fully ready to run only Klarna Payments, you must retain a KPM terminal to allow for the existing KPM orders to complete their processing. For example, a refund on a KPM order can only be delivered via the KPM terminal, using the Merchant Information Interface.
• As Klarna Payments is, effectively, a different payment method, any information you have stored against a customer using Klarna KPM will not migrate to the new method, and they will be required to provide it again.